\chapter{Módulo Comunicador de Erros}\label{capitulo4}

Uma das necessidades de qualquer sistema é a exatidão dos resultados obtidos através das operações disponíveis. É comum, durante a falha de um sistema, que o erro seja reportado de maneira insatisfatória. Isso ocorre, muitas vezes, pois o usuário não consegue transmitir os dados necessários para que o analista compreenda o que ocorreu, sendo muitas vezes papel do analista inferir o comportamento do usuário, o que também é uma fonte de erros.

O time de desenvolvimento do SacarWeb percebeu essa deficiência durante o levantamento de dados para correções do software. A comunicação entre usuário e desenvolvedor não é efetiva pois um lado não consegue compreender o outro \cite{Saiedian1999}. Para uma maior efetividade nas correções e alterações do SacarWeb, foi proposto um sistema de reporte de erros automático.

Este sistema será responsável pela construção de um \textit{log} de operações, onde serão armazenados dados relevantes sobre a navegação do usuário dentro do SacarWeb. Através do recurso de tratamento de exceções geradas pela linguagem de programação, serão exibidas páginas de reporte de erros quando um erro ocorrer. Nesta página, estará o \textit{log} do usuário, criado em um formato XML que garante a padronização da informação enviada. Ainda será possível ao usuário adicionar uma descrição textual do ocorrido para uma maior fidelidade de informações e para fornecer controle ao usuário. Outro fato importante na escolha do XML é que devido a utilização do DOM, visto que não será necessária a implementação de um \textit{parser} para ``navegar'' pelo arquivo e compreender sua sintaxe, o que seria necessário em um arquivo de texto, por exemplo.

Através deste módulo, pretende-se aumentar a efetividade da comunicação entre desenvolvedores e usuários e, conseqüentemente, melhorar o tratamento de \textit{bugs}, correções, alterações, \textit{upgrades} e versionamento do SacarWeb. Além disso, pretende-se estimular o usuário a utilizar a própria interface para comunicação dos erros, que ocorrerá de maneira pontual. Essa abordagem é extremamente vantajosa, visto que o usuário sabe exatamente o que ocorreu anteriormente a comunicação do erro, e caso ele não se recorde de algo, o \textit{log} criado pela aplicação auxiliará o desenvolvedor, durante a leitura do relatório com as informações do usuário e do \textit{log} do sistema, a compreender o que ocorreu. Melhorar a capacidade de expressão do usuário e de compreensão do desenvolvedor pode aumentar a efetividade da comunicação, o que pode melhorar também a efetividade do SacarWeb \cite{Gallivan2003}.

\section{Os tipos de usuário}
O SacarWeb possui uma classificação de usuários com papéis bem definidos dentro do sistema. Em questões de projeto, entretanto, um usuário possui diversos papéis, devido as tarefas que desempenha no sistema e ao conhecimento que possui do mesmo. Nesta abordagem, os papéis que um usuário pode desempenhar, dentro do SacarWeb, são \cite{Saiedian1999}:
\begin{itemize}
 \item Usuário Final: utilizam o sistema desenvolvido. São os mais familiarizados com processos de trabalho específicos endereçados pelo sistema;
 \item Especialistas de Domínio: são os que compreendem o ambiente do sistema ou problema do domínio em que o sistema é implantado. São a fonte de entrada técnica em relação a detalhes de interface e requisitos;
 \item Mantenedores de Software: responsáveis pelas mudanças de gerenciamento, implementação e resolução de anomalias. São os mais interessados em questões internas ao software como sua arquitetura e projeto.
\end{itemize}

Inicialmente, pode parecer estranho que um usuário desempenhe todos os papéis mencionados, entretanto, devido ao conhecimento de usuários como Especialistas em Saúde ou Administradores Locais, papéis com grande importância e conhecimento agregado do SacarWeb, certamente existirão casos em que serão desempenhados todos os papéis acima.

Entretanto, usuários Avaliadores, na maioria dos casos, estão se tornando Especialistas de Domínio, e utilizam o SacarWeb para ajudar nesse processo. Na maioria dos casos, também não possuem conhecimento suficiente para serem Mantenedores de Software, visto que não possuem informações históricas do mesmo, pois são usuários mais rotativos. Esse tipo de usuário é o mais abundante no sistema, e a maior fonte de dados acerca do comportamento do software. O maior beneficiado com o módulo em questão certamente será esse tipo de usuário.

\section{Processo de Comunicação de Erros}
Até o momento em que o módulo foi implementado, a comunicação dos erros era feita da maneira mais conveniente no momento para um determinado usuário. Na maior parte dos casos, essa tarefa foi realizada de duas maneiras: Verbalmente ou através de \textit{e-mail}.

A primeira delas acontecia de duas maneiras. Na primeira delas o erro era comunicado diretamente a equipe de desenvolvimento pelo usuário que o presenciou, assim que ele ocorria. Este caso ocorria raramente, devido ao distanciamento entre a equipe de desenvolvimento e os usuários. A segunda forma era através da comunicação por parte de um usuário Avaliador a um usuário Administrador. Este, por sua vez, comunicava a um membro da equipe de desenvolvimento que delegava a tarefa de correção a um dos membros da equipe. Essa era a forma mais comum de comunicação dos erros, devido a convivência diária dos usuários Avaliador e Administrador.

A comunicação por \textit{e-mail} também acontecia de maneira semelhante. Ou um \textit{e-mail} era enviado pelo Avaliador ao Administrador, que por sua vez enviava o mesmo \textit{e-mail} para um membro da equipe de desenvolvimento. Em alguns casos, não existia esse passo intermediário, sendo os \textit{e-mail}s enviados diretamente para o desenvolvedor. Na maioria dos casos algumas informações de maior utilidade eram anexadas, como capturas de tela feitas pelos usuários no momento em que ocorriam as falhas.

Nas duas formas de comunicação são encontrados erros no processo:
\begin{itemize}
 \item falta de padronização das informações e da própria maneira de comunicação;
 \item falta de informações relevantes;
 \item canais intermediários sujeitos a perda ou má interpretação da informação;
 \item falta de pontualidade, visto que o erro poderia ser comunicado dias após a sua ocorrência.
\end{itemize}

A não existência de um canal padrão para o reporte de erros e as deficiências em ambos os canais de comunicação já utilizados se tornaram os requisitos a serem atendidos pela ferramenta desenvolvida.

\section{Dados para Reporte de Erros}
Os dados que o usuário fornece são concisos, devido a grande quantidade de dados que a própria aplicação transmite através do \textit{log} de atividades. Entretanto, eles são de grande serventia, visto que características não capturáveis pela aplicação podem ser comunicadas pelo usuário. Os seguintes dados são de responsabilidade dos usuários:

\begin{itemize}
 \item descrição geral do erro;
 \item tarefa desempenhada como objetivo no momento;
 \item solução proposta;
 \item gravidade do erro (0-10);
 \item prioridade de desenvolvimento (0-10).
\end{itemize}

Além desses dados, a aplicação monta o \textit{log} de atividades que contém as seguintes informações:

\begin{itemize}
 \item identificação do usuário;
 \item informações de sessão do usuário \cite{Elbaum2003};
 \item informações de \textit{client-side};
 \item histórico de navegação;
 \item \textit{traceback} de exceção;
 \item mensagem de erro;
 \item cabeçalhos e variáveis \textit{Hypertext Transfer Protocol} (HTTP) durante a ocorrência do erro.
\end{itemize}

Todas essas informações auxiliam o analista e os desenvolvedores a descobrir a origem do erro ocorrido, assim como pensar rapidamente numa solução. Informações como gravidade do erro e prioridade de desenvolvimento ajudam na priorização das tarefas por parte dos desenvolvedores, que atenderão as maiores necessidades dos usuários com maior agilidade.

\section{Funcionamento do Módulo}

O módulo entra em funcionamento assim que um usuário realiza o login no SacarWeb. Ele é carregado juntamente à seção do usuário. Logo após o \textit{login}, informações sobre o usuário são adicionadas ao \textit{log}. Durante a navegação dele pelo sistema, são adicionadas as \textit{Uniform Resource Locators} (URL) que ele percorre. Caso o usuário realize o \textit{logout}, então o arquivo é destruído juntamente com a sessão do usuário. No caso de um erro, tratado por uma exceção ocorrer durante a navegação, então uma nova tela de reporte de erros é disponibilizada ao usuário. Nesta tela ele poderá adicionar informações que ele acredita que sejam relevantes aos dados que serão reportados. Adicionalmente aos dados fornecidos pelos usuários, dados capturados pelo módulo são colocados no arquivo de \textit{log}.

O usuário deve confirmar a operação de reporte de erro, então o arquivo é enviado para o desenvolvedor, que verifica através de uma área de reporte de erros que novas solicitações foram enviadas. Esta tela basicamente coloca as informações do arquivo dentro da própria aplicação, mas também é possível ao desenvolvedor realizar o \textit{download} do arquivo fonte e visualizar o mesmo em um editor de texto.Após a resolução das falhas, o desenvolvedor deverá marcar o reporte como resolvido. O fluxo de dados geral do módulo pode ser visto na figura \ref{fig:fluxo_report}. Já o formato do arquivo XML definido pode ser visto no apêndice \ref{ap:error}.
\begin{figure}[htb!]
    \centering
    \includegraphics[scale=0.45]{./figuras/report.png}
    \caption{Diagrama de Fluxo do Módulo de Reporte de Erros}
    \label{fig:fluxo_report}
\end{figure}

\section{Conclusões do Módulo de Reporte de Erros}
O gerenciamento de aplicações é uma tarefa que necessita de ferramentas que auxiliem na tomada de decisões de implementação e continuidade de projeto. O \textit{feedback} dos usuários é uma das principais ferramentas para se atingir um bom nível de fidelidade ao se questionar se a aplicação atende as necessidades para que ela foi projetada. Além disso, representa grande ajuda na tomada de decisões futuras e correções. Entretanto, existe a dificuldade atrelada a comunicação dos usuários com os desenvolvedores, que muitas vezes não se compreendem. O SacarWeb levantou essa falha e com objetivo de melhorar o processo de comunicação, foi implementada a ferramenta de reporte automático de erros.

Através desta ferramenta é possível enviar informações técnicas, necessárias para os programadores, e as informações que o usuário queira adicionar de maneira fácil, padronizada e no momento em que o erro ocorre. O módulo cria um \textit{log} de atividades do usuário assim que ele realiza o login no SacarWeb. Este \textit{log} contém informações relevantes para o programador, e que, na maioria dos casos, o usuário não seria capaz de transmitir. Entre eles temos dados referentes a sua sessão, ao navegador utilizado, passos executados, entre outras. Ainda assim o usuário possui a oportunidade de adicionar uma descrição do ocorrido, contribuindo para que o responsável compreenda o que ocorreu. Todo esse processo ocorre sem que o usuário perceba, sendo explicitado somente durante a ocorrência de um erro, através de uma tela de reporte de erros. A facilidade pode ser evidenciada pela necessidade do usuário apenas necessitar apertar um botão para o envio das informações, uma vez que a descrição que ele pode oferecer é opcional. A tela de reporte de erros pode ser vista na figura \ref{fig:error_report}.
\begin{figure}[htb!]
    \centering
    \includegraphics[scale=0.3]{./figuras/error_report.png}
    \caption{Tela de edição/adição de metadados}
    \label{fig:error_report}
\end{figure}
Toda essa informação é codificada em XML, sendo estruturada de maneira organizada para o responsável pela correção e, facilitando o gerenciamento das tarefas a serem realizadas pela aplicação. Isso também elimina a necessidade de implementações de interpretadores de texto, visto que a API DOM pode ser utilizada para XML.

O módulo possui pouco tempo de uso, entretanto os mantenedores do SacarWeb já podem usufruir de suas melhorias, monitorando as atividades de usuários pelo sistema, o que auxilia na compreensão de como o usuário se comporta, o que pode ser útil para melhorias de navegação, por exemplo. No que se refere a manutenção e correção de erros, o módulo ainda não teve grande utilização devido a pouca utilização, que ainda só se deu em fase de testes. Espera-se uma grande melhoria nesses aspectos, pois através da própria aplicação será possível realizar a gerência básica de tarefas. Por fim, percebemos outra possível maneira de comunicação em que o módulo poderá ser utilizado: como maneira de comunicação direta do usuário com a equipe de desenvolvimento. Para isso, um link foi inserido na aplicação, com acesso de qualquer tela, onde o usuário poderá sugerir melhorias ou correções, mesmo que nenhum erro tenha acontecido.